Frequently Asked Questions

Feature gates are a powerful tool for controlling the availability and behavior of features within an application. However, their scope of influence is limited to the application's internal features and does not extend to system-level settings or functionalities.

Specifically, feature gates cannot be used to hide custom keyboard extensions in system settings, as this would require direct interaction with the system's configuration, which is outside the purview of feature gates.

To achieve such functionality, developers would need to write code that interacts with the system settings directly.

Once such code is in place, feature gates can then be employed to control the execution of this code, effectively enabling or disabling the hiding of custom keyboard extensions based on the feature gate's configuration.

Currently, there isn't a feature to 'freeze' a gate in the way described. When a feature gate's status is changed to 'Launched' or 'Disabled', it will always return the default value (TRUE for Launched, FALSE for Disabled) for all users, regardless of whether they are new or old. The gate will stop generating billable exposure events, and you'll stop incurring costs. The gate reference is likely safe to be cleaned up in the codebase.

Implementing a feature to remember the previous evaluation for a gate would be challenging. However, if you want this sort of behavior, you could implement it yourself. If you have a client-side app, it would be fairly easy to store someone's evaluations in local storage, and check for a value there before checking Statsig.

For server-side implementation, you would need a database and a bit more work. This would allow you to store the evaluations and check for a value before checking Statsig, effectively creating a 'freeze' behavior.

Please note that these are workarounds and not built-in features of Statsig. If you have further questions or need assistance with a specific use case, please reach out for further assistance.

According to current capabilities, there isn't a feature that allows automatic rule creation for new feature gates based on certain tags. When a new feature gate is created, rules for that gate need to be added manually. However, there is a workaround to use the same rule across multiple feature gates.

This can be achieved by creating a segment with the desired criteria and then applying this segment to the rules of your feature gates.

Additionally, there is another method to simplify the process of creating new feature gates with a specific rule. You can create a template feature gate with your rule in it. Then, you can use the “clone” feature to create new identical gates with that rule.

This method allows you to replicate the rule across multiple feature gates without having to manually add it each time.

At present, there is no direct support for configuring the recipient of feature gate emails to an entire team instead of just the individual who created or edited it. However, there is an alternative way to receive notifications for a gate. Users can "subscribe" to them by clicking on the subscribe button. This will allow them to receive notifications related to the feature gate. Please note that this is the only other way to receive notifications for a gate currently supported.

In the context of managing feature gates within Statsig, the ability to rename an existing feature or experiment is not permitted.

This restriction is in place to avoid potential errors that could arise from renaming a feature that is already being referenced in the codebase, which could lead to the feature gate not returning the correct values.

If there is a need to change the name of a feature gate that has not yet been deployed, the recommended approach is to clone the existing feature gate and assign it the desired new name. This action will result in the creation of a new feature gate with the same configuration rules as the original, but it is important to note that the historical data and metrics associated with the original feature gate will not be transferred to the new gate.

Yes, it is possible to run feature gates within existing experiments. You can add new features to a variant by creating a feature gate that only passes for users who are in that variant. However, it's important to note that adding new features to a variant while an experiment is running could potentially impact the interpretation of the experiment results. Therefore, it's generally recommended to plan your experiment design carefully before starting the experiment to avoid making changes midway.

If you need to run multiple experiments or add new features, you might want to consider using layers. Layers are a powerful way to run many experiments in sequence, one building on top of the learning from the other. This could be a solution for running multiple experiments on the same users without having to change code.

Remember, once you start an experiment, it will run in all environments unless you set a targeting gate to restrict it to specific environments.

If you want to change the behavior of a variant, the recommended approach is to start a new experiment that is a vs. the new variant with the new feature being part of the new variant.

In scenarios where you wish to modify the default behavior of a feature gate in Statsig, which typically fails (returns false) when conditions are not met, there are alternative strategies you can employ.

One approach is to use negation operators within your conditions, such as 'not in' or 'not equal to', to effectively invert the logic of the gate. This allows you to create a condition that passes by default unless specified criteria are met. Another method is to adjust the 'fail' percentage to 100%. By doing so, you ensure that the feature gate fails for all users, effectively reversing the default 'off' state to an 'on' state.

These techniques allow for greater flexibility in controlling feature gate behavior and can be tailored to meet the specific needs of your experiment or feature rollout.

When a project member, who is part of a single review group, creates a new Feature Gate within a project that enforces reviews, the review group will not be automatically added to the ALLOWED REVIEWERS for the new Feature Gate.

The creation of a new Feature Gate does not require a review by the review group. However, any updates to the configuration of the Feature Gate will automatically include the review group as part of the review process.

In scenarios where there is a need to check feature flags for entities rather than individual users within the Statsig SDK, a workaround can be implemented using dynamic configs.

Dynamic configs in Statsig allow for the evaluation of different values for different IDs, which can be used as a substitute for feature flags by substituting user-specific checks with entity-specific checks. While dynamic configs do not support pulse, they share a common definition and evaluation method with feature flags, returning a JSON value instead of a boolean at the end of the evaluation process.

This approach can be particularly useful when dealing with long-lived sessions or when there is a need to frequently update the cache to reflect the latest configurations.

It is important to note that implementing a new SDK to handle this use case would be a more substantial undertaking, and utilizing dynamic configs as described may provide a viable solution without the need for such an investment.

In Statsig, feature gates are designed to control access to features based on user attributes or conditions, not on the number of times a user has accessed a feature. However, you can achieve the desired functionality by implementing a custom solution in your application code.

To limit the number of times a user can pass through a feature gate based on a count, you would need to maintain the state and count the times a user has accessed a feature. This can be done by incrementing a count stored in local storage or any other suitable storage system in your application.

Once you have the count, you can use a Custom Field targeting rule on the Gate that uses a numeric comparison operator. This rule should be set up to compare the stored count with the desired limit. When initializing the SDK, pass your stored count into the user object.

Please note that this approach requires you to manage the count state in your own system, as Statsig does not provide built-in support for this type of use case.

In Statsig, there is no built-in feature to make gate evaluations sticky for users. However, developers can achieve a similar effect by storing the result of a gate evaluation and then applying local overrides based on the stored result.

This method allows the gate value to remain consistent for the user, even if the conditions that originally allowed the user to pass the gate have since changed. To implement local overrides, developers can refer to the Statsig documentation on local overrides for guidance on how to set this up within their application.

The documentation provides the necessary steps and code snippets to help developers override gate values locally, ensuring that the user experience remains consistent as intended.

To schedule a feature gate roll out based on the environment in Statsig, you need to specify the environment during initialization and in your feature gate rules.

During initialization, set the environment tier as follows:

javascript options = {  environment: { tier: `${env}` }, }

After setting the environment tier, you need to specify the environment in your feature gate rules. Follow these steps:

1. Navigate to the Statsig Console and create or edit a Feature Gate.

2. When creating a rule for your Feature Gate, check the "Specify Environments" checkbox.

3. Choose the environments (like 'development' or 'staging') you want your rule to be enabled for.

4. Save your changes.

By default, unless otherwise specified, a rule is enabled for ALL environments. Therefore, it's crucial to specify the environment in your feature gate rules.

If your feature gate is not evaluating as expected, double-check the environment value you're passing during initialization. Ensure it matches exactly with the environment specified in your feature gate rules.

Remember, the order of rules in the Statsig console matters. If you have multiple rules, the first rule that matches the conditions will be applied. Therefore, if you have a specific rule for a certain environment, make sure it is placed before any general rules that could also apply.

In order to notify users before they are exposed to a new feature, you can create a separate feature gate to control the rollout percentage and a segment to contain the account IDs that can be exposed to the feature. This approach allows you to effectively manage the rollout process and ensure that users are notified in advance.

The main feature gate will only pass for the accounts in the segment that also pass the separate feature gate. This provides a clear distinction between the users who are eligible and those who have been exposed to the feature.

Here's a brief overview of the process:

1. Create a main feature gate (rollout_feature_gate). The users that pass this gate will be exposed to the feature.

2. Create a separate feature gate (exposure_eligibility_gate) to control the rollout percentage. The users that pass this gate are the ones eligible to be exposed to the feature.

3. Create a segment (allegeable_accounts) that contains all the account IDs that can be exposed to the feature.

The rollout_feature_gate will return pass only for the accounts in the allegeable_accounts segment, while questioning the exposure_eligibility_gate. After a certain amount of time, export all account IDs in the exposure_eligibility_gate to the allegeable_accounts segments, and increase the exposure_eligibility_gate percentage.

This approach allows you to have a distinction between the eligible users that were exposed to the feature (allegeable_accounts segment) to the ones that are allegeable but potentially not yet exposed to it (exposure_eligibility_gate). You can manage additional rules and environment conditions in the main feature gate (rollout_feature_gate).

Remember to test your setup thoroughly in a pre-production environment before rolling it out to ensure everything works as expected.

To display an indicator on your UI for features that are enabled only for specific segments, such as 'internal beta testers', you can utilize the Statsig Console API. This API allows you to programmatically retrieve detailed information about the rules associated with a specific feature gate. By using the Console API, you can determine which segments are currently receiving traffic for a given feature and display an appropriate indicator in your UI to reflect the rollout status to your beta testers or other user segments.

It is important to note that this approach requires special authorization via a new token, as it involves accessing potentially sensitive configuration data. The Console API is designed to be separate from the core SDK to ensure security and prevent unauthorized users from manipulating feature access.

For more information on how to use the Statsig Console API to fetch gate configurations, please refer to the official documentation provided in the Statsig Console API guide.

Currently, it is possible to add custom criteria for feature gating. You can create user targeting rules based on user attributes such as email and user ID, and additional ID types can be added in project settings. These can be used for all new experiments, allowing control over the experience a test user sees.

However, there isn't a feature to set these custom criteria as default options for a project. The ability to add these as default criteria options with a dropdown menu is not mentioned in the current documentation.

That being said, we are working on Templating features, and any default configuration criteria, including custom field defaults, are being considered. This includes the possibility of having default custom config for metrics so when the feature gate is created, the custom default metrics are selected/not selected.

In terms of the level at which these metrics are custom to, we are considering project-level defaults. This would be particularly useful for organizations with multiple teams utilizing different repositories, allowing for defaults to be set based on the specific project.

Please note that these features are currently in the scoping phase, and we are actively seeking input on feature requirements.

When utilizing the checkGate function within Statsig, it is imperative to provide a userID. This identifier is crucial as it ensures a consistent experience for each user. The userID is a mandatory field, as it is utilized to maintain uniformity in user experiences and is essential for the randomization process during partial rollouts.

It is important to note that even if an email is provided as a top-level field on StatsigUser, it does not substitute the requirement for a userID. In instances where there is no logged-in user, a stable identifier should be established, which could be stored as a cookie or in local storage, and used consistently with each call to Statsig.

This practice is vital for the system to function correctly and provide reliable results.

When utilizing the Statsig PHP SDK to send gate exposure data, it is expected that the events should appear in the Diagnostics event stream for the corresponding gate once the cron job is executed.

To ensure that the SDK is properly initialized and the cron job is configured correctly, developers should review their implementation. A typical initialization snippet and cron job usage are essential for troubleshooting any issues with event visibility on the Statsig dashboard.

If events are not appearing as expected, developers should verify that the SDK is correctly set up and that the cron job is functioning as intended.

It is important to ensure that the SDK is properly flushed before the process exits to guarantee that all events are sent to Statsig servers. If discrepancies persist after verification, further investigation into the SDK's event logging mechanism may be necessary.

In Feature Gate and Dynamic Config rules, the "equals" operator is not explicitly supported for numbers. However, there are alternative methods to achieve an equivalent functionality.

One such method is to use the "any of" operator with a single item in the array. This will effectively perform an equality comparison. Importantly, there is no need to cast integers to strings for this operation; the system handles the necessary conversions.

As a best practice, it is recommended to test this functionality to ensure it meets your specific requirements.

Remember, the operators provided in Feature Gate and Dynamic Config rules are designed to offer flexibility and cover a wide range of use cases. For numbers, operators like "greater than", "less than", "greater than or equal to", and "less than or equal to" are often more useful in defining conditions. If you need to check for an exact match, you could potentially use both "greater than or equal to" and "less than or equal to" with the same value to mimic an "equals" operation.

For any further questions or specific functionality needs, please reach out to the support team.

When you make a change in the Statsig Console, such as updating a targeting rule, it is expected that the new rule may take around 5 seconds to propagate. This is in line with our Service Level Objective (SLO). While an instant update might be desirable, it's important to note that this slight delay typically has no real impact on key metrics and user experience.

In the context of feature gates, for example, if you open a feature for Mac users and later remove access for Mac users and make it available for Windows users, there will be a slight delay before the change is reflected for Mac users. This is due to the Time To Live (TTL) associated with any type of hosted service.

Regarding the capacity of ID lists, each project can handle up to 10 million IDs. This means if you have 3 projects, each can handle its own list of 10 million IDs.